The computer system illustrated in FIG. 1 represents a typical hardware setup for executing software that allows a user to perform tasks such as communicating with other computer users, accessing various computer resources, and viewing, creating, or otherwise manipulating electronic content—that is, any combination of text, images, movies, music or other sounds, animations, 3D virtual worlds, and links to other objects. The system includes various input/output (I/O) devices (mouse 103, keyboard 105, display 107) and a general purpose computer 100 having a central processor unit (CPU) 121, an I/O unit 117 and a memory 109 that stores data and various programs such as an operating system 111, and one or more application programs 113.
As shown in FIG. 2, a user of a computer system can access electronic content or other resources either stored locally at the user's own client system 202 (e.g., a personal or laptop computer) or remotely at one or more server systems 200. An example of a server system is a host computer that provides subscribers with online computer services such as e-mail, chat rooms, Internet access, electronic newspapers and magazines, etc. Users of a host computer's online services typically communicate with one or more central server systems 200 through client software executing on their respective client systems 202. In practice, a server system 200 typically will not be a single monolithic entity but rather will be a network of interconnected server computers, possibly physically dispersed from each other, each dedicated to its own set of duties and/or to a particular geographical region. In such a case, the individual servers are interconnected by a network of communication links, in known fashion. One such server system is “America Online” from America Online, Incorporated of Virginia.
A “browser,” as depicted in FIG. 3A, is an application that enables users to access and view electronic content stored either locally or remotely, such as in a network environment (local area network (LAN), intranet, Internet). A typical browser window 300 provides a user with several options for specifying the particular content that the user desires to view. For example, the user can access a pull-down menu from a menu bar 302 to identify a particular file or address to open, or the user can manually type an address (e.g., Uniform Resource Locator (URL)) corresponding to the desired content in an Address field 304.
Several types of user applications maintain history state information identifying the programs, files or other content most recently accessed. A word-processing program, for example, may maintain a short drop-down menu showing three or four recently opened files, which a user can then easily re-open with a single click of the mouse button. A browser similarly keeps track of the history of addresses or locations accessed by the user, and uses this history information to provide the user with mechanisms for moving among the locations previously visited.
More particularly, as a user accesses content at a particular address and then moves on to a new address, and after that another new address and so on, the browser 300 keeps track of the past files or addresses that the user has visited or otherwise accessed. If the user subsequently desires to return to one of these locations, the browser may provide several different mechanisms for doing so, for example as shown in FIG. 3A, through a drop-down window 310 referred to as a “history list”, and/or by using Back and Forward buttons 306 and 308, which provide stepwise access to the browser's “navigation tree”—a logical construct that defines the next location to jump to when either the Back 306 or Forward 308 buttons are clicked.
In the example shown in FIG. 3A, a user presently accessing page5 can return to the immediately previous location, page4, either by clicking the cursor once on the Back button 306 or by clicking the cursor first on the combo-box button 311, which causes the history list 310 to be displayed, and then clicking the cursor on the second topmost entry 312 in the history list 310. Subsequently, the user either can continue clicking the Back button 306 to step back through the addresses previously visited as defined by the browser's navigation tree (e.g., page3, page2, and page1 in that order) or can click on the Forward button 308 to return to the location from where the user just came, page5. In addition, the user can randomly access any of the entries in the history list 310 by clicking the cursor on the desired location. Or the user can jump to some altogether new location, for example, by typing an address in the Address field 304, by using menu functions in the menu bar 302, or by clicking on a link 320 displayed in the browser window 300.
Whenever the browser jumps to another location, by whatever means, the history list 310 and the navigation tree may be updated or otherwise modified to reflect the current navigation state. For example, as shown in FIG. 3B, if a user jumps to a new location not yet visited (e.g., page6), the Address field 304 displays the new address and the history list is modified by inserting a new entry 322 immediately below the Address field 304 to list the previous location (page5). The rest of the history entries 312-318 already in the history list 310 are shifted down by one row to make room for the new entry 322. If the history list 310 becomes too lengthy, the browser may delete the oldest entries to make room for each new location visited.
By way of another example, if the user then jumped to a previously visited location by clicking on an entry displayed in the history list 310, for example, page3, the browser would update the history list to appear as in FIG. 3C, in which the same entries appear but in a different order. Specifically, the updated history list 310 shown in FIG. 3C displays the now current address, page3, in the Address field 304, and the other previously visited locations are displayed below the Address field 304 in the order in which they were last visited (most recently visited at top, oldest at bottom). An entry for page3 no longer is displayed below the Address field 304 because the history list 310 typically will not contain duplicate entries for a location even though, as in this example, that location was visited more than once.
For each jump to another location, whether previously visited or not, the browser also updates or modifies its navigation tree as appropriate. FIG. 4A depicts a navigation tree in which the circles represent the different locations visited and the arrows represent jumps from one location to the next. The particular navigation tree example in FIG. 4A represents an order of events in which a user makes nine jumps to visit seven different locations in the following order: page1→page2→page3→page4→page5→page4→page5→4 page6→page3→page7.
FIG. 4B, a table corresponding to the navigation tree shown in FIG. 4A, shows state information associated with the Back and Forward buttons at each of the nine jumps. During the first four jumps (page1→page2→page3→page4→page5) the Back Button State accumulates and stores each of the successive locations for potential future use if the user clicks the Back button. After jump 4, for example, the user could click the Back button four times in succession to traverse the navigation tree in reverse order (page5→page4→page3→page2→page1).
In the first five states (jumps 0-4), because the user has not returned to any previously visited location, the Forward Button state remains empty (i.e., no Forward jump location is defined). At jump 5, however, the Forward Button state reflects that a single jump in the Forward direction (to page5) is available because the user has returned to a previously visited location (page4). At jumps 6 and 7, the Forward Button state again becomes empty as the user moves on to a new location, page6.
At jump 8, as shown in FIG. 4A, the user has traveled backward in the navigation tree from page6 directly to page3, for example, by selecting the page3 entry from the history list. At this point, as shown in FIG. 4B, the Back button state information points to page2 and then to page1 (in that order, assuming successive clicks of the Back button), while the Forward button state information points to page4, page5, and then to page6 (in that order, assuming successive clicks of the Forward button).
At jump 9, the user decides to view a new location and thus points the browser (e.g., by typing in an address in the Address field) to page 7, at which point the navigation tree is “pruned.” That is, the navigation tree is modified to reflect the current state and to ensure that subsequent clicks of the Back and Forward buttons provide users with a predictable response. In the specific example of the navigation tree shown in FIG. 4A, all three of the locations within the dotted region 400—page4, page5 and page6—are removed from the navigation tree as a result of the pruning that occurs when the user moved from page3 to page7. Consequently, as shown in FIG. 4B, the Forward button state again becomes empty and the Back button state information specifies that three successive clicks of the Back button would cause the browser to move from page7 to page3, page2 and page1 in that order. Pruning of the navigation tree in this fashion typically is independent of, and does not affect, the order or identity of locations displayed in the history list—that is, all seven locations page1-page7 still would appear in the history list even though page4-page6 were pruned from the navigation tree for the Back and Forward buttons.